• Introduce optee-teec-plugin-bindgen crate to generate plugin bindings for plugin developers, replacing optee-teec-macros.
• Refactor optee-teec::PluginParameters and add additional methods.
• Update optee-teec-sys::PluginMethod to latest version.

With these changes, plugin development now only requires adding optee-teec-plugin-bindgen as a build dependency and including the generated artifact in lib.rs.

Why not use a proc macro?

I have thought about implementing a declare_supp_plugin macro like thisdemo:

declare_supp_plugin!(
    name: "my_plugin",
    uuid: "ef620757-fa2b-4f19-a1c4-6e51cfe4c0f9",
    init: my_init,
    invoke: my_invoke,
);

Developers can use it like:

use optee_teec::{declare_supp_plugin, PluginParameters};

fn plugin_init() -> optee_teec::Result<()> {
    println!("*plugin*: init, version: {}", env!("CARGO_PKG_VERSION"));
    Ok(())
}

fn plugin_invoke(_: &mut PluginParameters) -> optee_teec::Result<()> {
    println!("*plugin*: invoke");
    Ok(())
}

declare_supp_plugin!(
    name: "syslog",
    uuid: "ef620757-fa2b-4f19-a1c4-6e51cfe4c0f9",
    init: plugin_init,
    invoke: plugin_invoke,
);

The main issue is that developers may provide the UUID through a variable. Due to the limitations of proc macros, we cannot resolve the value of that variable during macro expansion. As a result, the UUID would need to be parsed and converted at runtime.

declare_supp_plugin!(
    name: "my_plugin",
    uuid: proto::PLUGIN_UUID,  // proc_macro cannot resolve the value at compile time.
    init: my_init,
    invoke: my_invoke,
);

However, this introduces another problem: what happens if UUID parsing fails? Triggering a panic in a shared library is not a good idea and should be avoided.